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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention generally relates to computer systems, and in 
particular, to a method and apparatus for providing a secure-private partition on a 
hard disk drive. 

2. Description of the Related Art 

In the field of computer systems, various implementations have been 
proposed for protecting data stored in a computer from being accidentally or 
intentionally deleted or corrupted. For example, firmware functions and other 
codes, data, files stored in flash memory and other nonvolatile memory are 
protected from deliberate distortion of information. In one type of flash memory 
(i.e., boot block type) the codes and data can be locked and updated only in a 
special manner. Due to increases in complexity of computer systems, firmware 
functions and features within system ROM (read-only memory) utilizing flash 
memory (or other nonvolatile memory) continue to grow in size. This growth of 
firmware creates a problem of adding more functions and features without having 
enough memory space to store these new functions. Unfortunately, the cost of 
flash memory and other nonvolatile memory continues to remain relatively high. 
Because hard drive storage continues to get faster and cheaper, it would be 
desirable to create a secure partition on a hard disk drive which may serve as an 
expansion memory for platform expansion functions. 

There is also a need to protect certain software stored in computer 
systems from computer viruses. Once a computer is infected with a computer 
virus, codes, data, files stored in a hard disk drive is vulnerable to unauthorized 
corruption. Therefore, there is a need to provide a secure partition on a hard disk 
drive that is capable of protecting the software stored in the secure partition from 
being accidentally or intentionally deleted or corrupted. 
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FIG. 1 is a block diagram of one embodiment of a computer system 
suitable for use with the present invention. 

FIG. 2a is a flowchart of operations for requesting and storing master 
token according to one embodiment of the present invention. 

FIG. 2b is a flowchart of operations for opening a secure-private partition 
of a hard drive according to one embodiment of the present invention. 

FIG. 3 is a flowchart of operations for reading/writing data to/from the 
secure-private partition according to one embodiment of the present invention. 

FIG. 4 is a block diagram of a security/privacy system according to one 
embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

One implementation of the present invention is described herein for 
purposes of illustration, namely a method and a corresponding system for 
providing a secure-private partition (SPP) on a storage device (e.g., hard disk 
drive) of a computer system. The SPP is accessible only through the use of 
special operations to minimize or eliminate the chance of data being accidentally 
or intentionally deleted or corrupted. The special operations for accessing the 
SPP will be discussed in detail with reference to FIGS. 2a, 2b and 3. 

Referring to FIG. 1, one embodiment of a computer system in which a 
method of the present invention may be implemented. The computer system 100 
includes a processor 105 coupled to a processor bus 110. In one embodiment, 
the processor 105 is a processor from the Pentium® family of processors 
including the Pentium®, Pentium® Pro, Pentium® II and Pentium® III processors 
available from Intel Corporation of Santa Clara, California. Alternatively, other 
processors may be used. The processor 105 may include a first level (L1) cache 
memory (not shown in Figure 1). 
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In one embodiment, the processor 105 is also coupled to a cache memory 
107, which is a second level (L2) cache memory, via a dedicated cache bus 102. 
The L1 and L2 cache memories can also be integrated into a single device. 
Alternatively, the cache memory 107 may be coupled to the processor 105 by a 
shared bus. The cache memory 107 is optional and is not required for the 
computer system 100. 

A chip set 120 is also coupled to processor bus 1 10. Included in the chip 
set is an Integrated Device Electronics (IDE) controller. A main memory 1 13 is 
coupled to the processor bus 1 10 through the chip set 120. The main memory 
113 and the cache memory 107 store sequences of instructions that are 
executed by the processor 105. In one embodiment, the main memory 113 
includes a dynamic random access memory (DRAM); however, the main memory 
113 may have other configurations. The sequences of instructions executed by 
the processor 105 may be retrieved from the main memory 113, the cache 
memory 107, or any other storage device. Additional devices may also be 
coupled to the processor bus 110, such as multiple processors and/or multiple 
main memory devices. The computer system 100 is described in terms of a 
single processor; however, multiple processors can be coupled to the processor 
bus 1 10. A video device 125 is also coupled to the chip set 120. In one 
embodiment, the video device includes a video monitor such as a cathode ray 
tube (CRT) or liquid crystal display (LCD) and necessary support circuitry. 

The processor bus 1 10 is coupled to a system bus 130 by the chip set 
125. In one embodiment, the system bus 130 is a Peripheral Component 
Interconnect (PCI) standard bus; however, other bus standards may also be 
used. Multiple devices, such as an audio device 127, may be coupled to the 
system bus 130. A bus bridge 140 couples the system bus 130 to a secondary 
bus 150. In one embodiment, the secondary bus 150 is an Industry Standard 
Architecture (ISA) bus; however, other bus standards may also be used, for 
example an Extended Industry Standard Architecture (EISA). A hard drive 153 
may be coupled to the secondary bus 150. Other devices, such as cursor control 
devices (not shown in Figure 1), may be coupled to the secondary bus 150. 
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Referring to FIG. 4, a block diagram of a security/privacy system 400 
according to one embodiment of the present invention is shown. In the illustrated 
embodiment, the security/privacy system 400 includes a privacy gatekeeper 402 
and a security/privacy software task 404. Also illustrated in FIG. 4 is an IDE 
controller 410, which provides for the attachment of IDE compatible storage 
devices such as a hard disk drive 416. The hard disk drive 416 includes a disk 
controller 418, which reside on the drive itself. The hard disk drive 416 is 
partitioned into a standard partition 422 and a secure-private partition (SPP) 420. 

The SPP is operable in a locked mode and an unlocked mode, wherein 
the SPP is invisible to the operating system in the locked mode and the SPP is 
visible to the operating system in the unlocked mode. Normally, the SPP is 
hidden from the operating system until the partition is unlocked. 

According to one aspect of the invention, the operations of the present 
invention relating to opening, accessing and closing of the SPP 420 are carried 
out in part by the IDE controller 410 which works in harmony with the disk 
controller 418 on the hard drive 416. Although an IDE controller is used in the 
illustrated embodiment, it should be understood by those skilled in the art that 
other types of controllers may be used for interfacing with the hard drive. 

The SPP 420 is configured to unlock when a handshake is established 
between the IDE controller 410 and the security/privacy software task 404. The 
security/privacy software task 404 is a software or firmware (e.g., running at 
operating system privilege level) that is knowledgeable about the unlock 
handshake. In one embodiment, the security/privacy software task 404 requests 
a master token 426 from the IDE controller 410 when the computer is turned on 
for the very first time. This master token 426 is generated only one time by the 
IDE controller 410 and is required to unlock the SPP 420. The master token 426 
could also be generated by the disk controller 418. The master token 426 issued 
by the IDE controller 410 or the disk controller 418 is stored in a secure storage 
location 408 for later use. The master token may be kept secure through any 
suitable security method for storage and subsequent use of the token, including 
encryption methods. 
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Also shown in FIG. 4 is a requesting software 414, which is a code that 
needs to access the SPP. When the requesting software 414 makes a request to 
access the SPP, the privacy gatekeeper 402 acts as a gatekeeper to the 
security/privacy software task 404. In this regard, the privacy gatekeeper will 
prescreen the request by validating a handshake (e.g., a secure token). Thus in 
order to initiate the process of accessing the SPP, the requesting software 414 
will retrieve (or generates) a secure token 412 that is required by the privacy 
gatekeeper 402. The requesting software 414 makes a function call to the 
privacy gatekeeper 402 with the secure token 412 as one of the parameters to 
the function call. If the privacy gatekeeper 402 validates the handshake from the 
requesting software by verifying the secure token 432, it will return a unique 
access token 434 to the requesting software 414 for subsequent access. This 
validation by the privacy gatekeeper 402 causes the security/privacy software 
task 404 to send the master token 424 to the IDE controller to unlock (i.e., make 
visible) the SPP. The master token from the security/privacy system is in turn 
validated by the IDE controller to ensure that it is the proper master token to 
unlock the SPP. 

In accordance with another aspect of the invention, several different levels 
of security may be provided. In one embodiment of the present invention, the 
SPP may be configured to be private only. In this embodiment, when the SPP is 
unlocked, the partition is visible to the operating system and is generally 
accessible by other software. To prevent other software from accessing the 
SPP, the SPP is preferably locked back up once a series of (e.g., read/write) 
access thereto has been completed. The locking of the SPP upon completion of 
the access reduces the risk of damages to the partition content caused by an 
intentional act (e.g., repartition and format) or a malicious act (e.g., computer 
viruses). The locking of the SPP will be discussed in detail with reference to FIG. 
3. 

In another embodiment of the present invention, the access to the SPP 
can be made secure by utilizing encryption techniques to prevent other software 
from accessing the SPP when it is unlocked. In this embodiment, the data stored 
on the SPP can be encrypted using standard encryption techniques through 

5 
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either software or hardware encryption or a combination. As a result, the 
encrypted data in the SPP is readable only when an access thereto is 
accompanied by a special "key" to decode the encrypted data. 

In yet another embodiment of the present invention, the access to the SPP 
420 is made secure by requiring that each access request (e.g., read/write) be 
accompanied with a proper handshake. As described above, the SPP 420 is 
configured to be locked (i.e., the partition is hidden) and unlocked (i.e., the 
partition is visible). In this embodiment, once the partition is unlocked, each 
access request to the SPP must be accompanied by a proper handshake. The 
IDE controller 410 generates and returns a usage token 428 to the 
security/privacy system upon unlocking the SPP. The usage token 428 is stored 
in a secure location 406 so that it can be used later to access the content of the 
SPP. When the requesting software 414 needs to execute memory access, the 
requesting software uses the unique access token 436, which it has received 
earlier, to execute an access to the SPP. More specifically, the requesting 
software 414 makes a function call to the privacy gatekeeper 402 with the unique 
access token 436 as one of the parameters to the function call. The 
security/privacy software task 404 will in turn send an access request 
accompanied by the usage token 430 to the IDE controller 410, upon validation 
of the access token 436 by the privacy gatekeeper. The IDE controller 410 will 
only grant requests to access the SPP 420 in the case when the request is 
accompanied by a proper usage token 430. Because a usage token 430 is 
required with every access request, it is not possible for any piece of software to 
read, write, and/or destroy data on the SPP even when the SPP is unlocked. 

Referring to FIG. 2a, the general operations of requesting and storing 
master token according to one embodiment of the present invention is shown. In 
functional block 200, the security/privacy software task 404 responsible for 
managing a secure link for the SPP 420 requests a master token 426 from the 
IDE controller 410 (or disk controller 418) when the computer is turned on for the 
very first time. Then in block 205, the master token received from the IDE 
controller or the disk controller is stored in a secure storage location 408 for later 
use. 
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Referring to FIG. 2b, the general operations of opening the SPP according 
to one embodiment of the present invention is shown. It should be noted that the 
term "opening" of the SPP in the context of the present invention is used to 
describe the process of unlocking the SPP so that the SPP is visible to the 
operating system. In decision block 210, a determination is made whether an 
access to the SPP is needed. The need to access the SPP may be triggered by 
various reasons. For example, perhaps a user clicked on an icon requesting 
additional system diagnostics software to be executed which are stored on the 
SPP or the user may have requested that the standard OS image be refreshed 
from the backup image stored on the SPP. In this example, the act of user 
clicking on an icon causes the operating system to start a program or task 
associated with that icon. The task (referred as requesting software 414 in FIG. 
4) is perhaps a code that knows that it needs to access the SPP and the access 
mechanism (e.g., handshake) that must occur for that interface to be opened. 

When the requesting software 414 needs to access the SPP (decision 
block 210, YES), the requesting software retrieves (or generates) a secure token 
412 that is expected by the privacy gatekeeper 402 and makes a function call to 
the privacy gatekeeper with the secure token as one of the parameters to the 
function call. Once the privacy gatekeeper 402 has validated the handshake 
from the requesting software 414, the security/privacy software task 404 retrieves 
the master token from the secure storage location 408 in functional block 215. 
Then in functional block 220, the security/privacy software task 404 requests an 
open access to the SPP by making a function call to the IDE controller with the 
master token as one of the parameters. In order to validate whether it can 
continue with the command to open the private partition, the IDE controller 
validates the master token. The IDE controller passes the master token through 
it's internal hash mechanism and compares the result to verify that it is a valid 
token. 

If the handshake is validated (decision block 225, YES), the IDE controller 
unlocks the SPP in block 230, causing the partition to be visible to the operating 
system. Then in functional block 235, the IDE controller 410 generates and 
returns a new usage token 428 to the security/privacy software task 404 for 
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subsequent access to the SPP. In one embodiment, the privacy gatekeeper 402 
may pass the new usage token 428 to the requesting software 414 for 
subsequent access. In an alternative embodiment, the requesting software may 
receive a new usage token directly from the IDE controller for subsequent access 
to the SPP. Because the usage token 428 is required to gain access (e.g., 
read/write) to the SPP, only a software having access to the usage token will be 
granted read/write access. In this regard, although the SPP is generally available 
to other software when it is unlocked, the usage token serves to prevent 
unauthorized access to the SPP. In the example where the requesting software 
is a software requesting additional system diagnostics software to be executed 
which are stored on the SPP. In this example, the requesting software will use 
the usage token in subsequent series of calls to find, open and run the diagnostic 
software that has been previously stored on the SPP. 

According to one aspect of the present invention, multiple usage tokens 
may be assigned to allow access to different portions of the SPP. In this regard, 
the SPP may be further partitioned into multiple sub-partitions. A security stack 
may be used to generate a new usage token for each sub-partition. In this 
regard, the security stack will issue a usage token to a software program that has 
initiated the unlock sequence for a particular sub-partition. In this regard, each 
software program having access to the SPP may use its usage token to gain 
access only to that particular sub-partition, however that usage token will not 
allow access to the rest of the SPP. 

In one embodiment, the new usage token is implemented by the software 
writing the initial handshake token to a defined input/output port and then reading 
back the usage token. Then, the requesting software 414 executes read/write 
requests in functional block 240 and closes the access to the SPP in functional 
block 245, the details of which will be discussed with reference to FIG. 3. If the 
handshake is not validated (decision block 225, NO), the IDE controller will not 
unlock the SPP (i.e., the SPP will remain hidden from the rest of the computer 
system) and the system returns to decision block 210. 
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Any requests to the IDE controller to determine disk characteristics (e.g., 
number of partitions, type of partition, partition initialization, etc) will not return 
any valid information about the SPP unless it has been unlocked by submitting a 
valid master token with the request. Under general circumstances, operating 
systems and their associated device drivers for hard disks will not pass any sort 
of token to the IDE controller. Virus software or errant software may pass a 
token to the IDE controller, but the worst thing that could happen is that such 
software will keep the IDE controller busy rejecting requests as the rogue 
software tries all possible number combinations of a potentially large access 
token (e.g., perhaps 40-bit or128-bit tokens may used). In one embodiment, the 
IDE controller may be made intelligent so that after seeing a predetermined 
number of invalid requests since the last power cycle, the IDE controller disables 
all access to the SPP or the entire hard drive in recognition of an attempt by the 
unscrupulous software to gain unauthorized access. In this case, a flag 
indicating the number of invalid accesses would be reset when the power is 
turned off. The chances of errant or virus software gaining access to the SPP is 
limited by the computer system's ability to churn through number permutations 
but also by a time factor - it would take a rather long time (e.g., one million 
years) for a software to run through all possible numbers of a 128-bit token when 
the power must be cycled off-on after a certain amount of invalid attempts (e.g., 
10). 

Referring to FIG. 3, an expanded flowchart of functional blocks 240 and 
245 of FIG. 2 is shown, illustrating the general operations of performing 
read/write requests and closing of the SPP according to one embodiment of the 
present invention. The software's request to read/write data to/from the SPP can 
be user initiated by selecting an application menu, clicking on an icon, starting 
the computer or other user-initiated actions. Alternatively, the software's 
requests to read/write data to/from the SPP can also be automatically generated 
without user intervention such as when local storage of a background process 
exceeds available RAM and needs mass storage, or when additional execution 
code for a background task needs to be loaded from the private partition. 
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After the SPP has been opened, the usage token may be available to the 
security/privacy software task 404. Alternatively, the usage token may be 
available to the requesting software 414 for directly communicating with the IDE 
controller 410. In this case, the requesting software 414 submits a read/write 
request for data stored in the SPP in functional block 300. Then in functional 
block 305, the requesting software 414 passes the usage token (directly or via 
the security/privacy system 400) to the IDE controller 410 since every read/write 
access request to the SPP must be accompanied by a proper usage token to be 
successful. Then in decision block 310, a determination is made for every 
read/write request by the IDE controller whether the usage token passed in by 
the requesting software is valid before continuing with the request. If the usage 
token is valid (decision block 310, YES), the request is granted, allowing the 
requesting software to perform read/write operations on the SPP in functional 
block 320. The usage token should be frequently changed to optimize security. 
In the illustrated embodiment, the IDE controller generates and returns a new 
usage token after each read/write access in functional block 323. If the usage 
token is invalid (decision block 310, NO), access to the SPP is denied and an 
error is returned to the requesting software using a well-known error return code 
in functional block 315. 

When the requesting software (such as the application program which 
requested the usage of the SPP) has completed it's read/write access and would 
like to close the SPP (block 325, YES), it passes the usage token down through 
the same software path down to the IDE controller in functional block 330. It 
should be noted that the term "closing" of the SPP in the context of the present 
invention is used to describe the process of locking the SPP so that the SPP is 
hidden from the operating system. Then in decision block 335, the IDE controller 
again validates the usage token. If the usage token is valid (block 335, YES), the 
SPP is locked in functional block 340, meaning that the partition is hidden from 
the rest of the computer system (e.g., operating system). Then in functional 
block 345, the usage token gets clears out. After the SPP has been properly 
locked, subsequent requests to access the SPP, even with the last known usage 
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token will be denied until the SPP is opened or unlocked by using the master 
token as previously mentioned with regard to blocks 210-230 of FIG. 2. 

In yet another embodiment of the invention, additional security feature 
may be incorporated into the hard drive 416 itself such that the access to the 
SPP 420 will only be granted by the hard drive 416 if a proper handshake is 
established between the disk controller 418 and the IDE controller 410. Various 
techniques can be used to implement a handshake between the IDE controller 
410 and the disk controller 418. For example, a handshake connection between 
the IDE controller and the hard disk controller is accomplished by new definitions 
of redundant ground pins on an IDE interface connector. For example, a 
handshake may be established when the handshake enables a certain pin on the 
IDE interface connector to be grounded. This handshake may be executed a 
program to set a certain pin on the IDE interface connector to ground. In another 
embodiment, a handshake connection between the IDE controller and the hard 
disk controller is accomplished by strobing all address and data lines high, 
followed by a handshake token passed through the data lines with the address 
lines pulled low. 

The SPP formed in accordance with the present invention may provide a 
number of advantages. For example, the SPP may serve as an expansion 
memory for platform expansion functions, storing enhancements to standard 
firmware functions. If new functions need to be added to system firmware and 
there is no more nonvolatile storage available, the system ROM can be 
segmented to load additional feature code from the SPP of the hard disk by 
initiating the handshake between the system chipset and the controller on the 
hard drive. In this regard, computer systems may continue to expand platform 
functions without having to increase the size of system's flash or other nonvolatile 
memory. In addition, the secure/private may provide a static/semi-dynamic 
storage for functions that are normally kept in system ROM (nonvolatile system 
memory). The SPP can also used to contain software files that will never be 
updated, such as encryption software or other data that should be protected from 
computer viruses or mishap at all costs. 
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Alternatively or in addition to above stated purposes, the SPP may be 
used to store codes that are associated with, for example: (1) reinitializing 
platform to standard IT configuration; (2) diagnostics - if the system crashes or 
there is a hardware failure, diagnostic code can be loaded from this partition to 
5 analyze and possibly repair the system; (3) extended firmware functions; (4) 
secure content validation; (5) user authentication; (6) encryption/decryption; (7) 
freeze dried operating system image; (8) MPEG (Moving Pictures Experts Group) 
functions or other multimedia functions with universal decode interface; and (9) 
any other static functions that normally are stored in flash memory. The freeze 
10 dried operating system image is useful in the case where through accident or 

malice, the software on the hard drive is damaged such that the operating system 
will no longer load. In this case, the system firmware can be invoked through a 
special command (e.g., a special keystroke) to restore the hard disk image from 
the SPP. 

15 While the foregoing embodiments of the invention have been described 

and shown, it is understood that variations and modifications, such as those 
suggested and others within the spirit and scope of the invention, may occur to 
those skilled in the art to which the invention pertains. The scope of the present 
invention accordingly is to be defined as set forth in the appended claims. 
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CLAIMS 

What is claimed is: 

1 1. A method comprising: 

2 providing a partition on a storage device of a computer system, wherein 

3 said partition is normally invisible to an operating system of the computer system 

4 unless the partition is unlocked; and 

5 unlocking the partition in response to an unlock request received from a 

6 software task having knowledge about a proper handshake to unlock the 

7 partition, wherein the partition is visible to the operating system when it is 

8 unlocked. 

1 2. The method of claim 1 , wherein the storage device is a hard disk drive 

2 having a disk controller. 

1 3. The method of claim 1 , wherein the unlocking of the partition is initiated 



2 by establishing a proper unlock handshake between the software task and an 

3 IDE controller for controlling the storage device. 

1 4. The method of claim 3, wherein the software task requests a master 

2 token from the IDE controller when the computer system is first turned on and the 

3 unlock handshake between the software task and the IDE controller is 

4 established by passing the master token back to the IDE controller as a 

5 parameter. 



1 5. The method of claim 2, wherein the software task requests a master 

2 token from the disk controller when the computer system is first turned on, said 

3 master token is used by the software task to initiate the proper handshake to 

4 unlock the partition. 

1 6. The method of claim 1 , further comprising preventing an access to the 

2 partition when the partition is unlocked unless the access is requested by a 

3 software having knowledge about a proper access handshake for accessing the 

4 partition. 

13 



042390.P8691 



Express Mail No. EM5 60648 119US 



1 7. The method of claim 6, wherein the software receives a usage token 

2 from an IDE controller when the partition is unlocked and the access handshake 

3 between the software and the IDE controller is established by passing the usage 

4 token back to the IDE controller as a parameter. 

1 8. The method of claim 1, further comprising locking the partition in 

2 response to a lock request received from a software having knowledge about a 

3 proper handshake for locking the partition. 

1 9. The method of claim 1, further comprising providing a standard partition 

2 on the storage device, wherein said standard partition is always visible to the 

3 operating system and generally accessible to other softwares. 

1 10. A machine-readable medium that provides instructions, which when 

2 executed by a set of processors, causes said set of processors to perform 

3 operations comprising: 

4 receiving an open request from a software to access a secure-private 

5 partition on a hard drive of a computer system; 

6 validating the open request received from the software; and 

7 requesting unlocking of the secure-private partition in response to the 

8 validation of the open request received from the software. 

1 11. The machine-readable medium of claim 10, wherein the operations 

2 further comprise requesting locking of the secure-private partition in response to 

3 a close request received from the software. 

1 12. The machine-readable medium of claim 10, wherein the requesting of 

2 the unlocking of the secure partition further comprises: 

3 requesting a master token from an IDE controller when the computer 

4 system is turned on; 

5 storing the master token in a secure storage location; 

6 retrieving the master token from the secure storage location when an 

7 access to a secure-private partition is needed; and 

8 passing the master token as a parameter to the IDE controller. 
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1 13. The machine-readable medium of claim 10, wherein the operations 

2 further comprise requesting an access to the secure-private partition in response 

3 to an access request received from the software. 

1 14. The machine-readable medium of claim 13, wherein the requesting of 

2 the access to the secure partition further comprises: 

3 receiving a usage token; and 

4 passing the usage token to the IDE controller to gain an access to the 

5 secure partition. 

1 15. The machine-readable medium of claim 10, wherein the request from 

2 the software to access the secure-private partition is received by a privacy 

3 gatekeeper which prescreens the request to determine if the software has an 

4 authorization to access the secure-private partition. 

1 16. A system comprising: 

2 a storage device having a storage controller, said storage device having at 

3 least one secure-private partition, wherein said secure- private partition is 

4 selectively in one of locked and unlocked modes, wherein said secure-private 

5 partition is invisible to an operating system when it is locked and the secure- 

6 private partition is visible to the operating system when it is unlocked; 

7 an IDE controller operatively coupled to the storage controller; and 

8 a security/privacy software task operatively coupled to the IDE controller, 



9 wherein said IDE controller initiates an unlock request to unlock the secure- 

10 private partition in response to a valid unlock handshake established between the 

1 1 IDE controller and the security/privacy software task and said IDE controller 

12 initiates a lock request to lock the secure-private partition in response to a valid 

13 lock handshake established between the IDE controller and the security/privacy 

14 software task. 

1 17. The system of claim 16, wherein the security/privacy software task 

2 requests a master token from the IDE controller when the system is turned on 

3 and sends the master token to the IDE controller as a parameter when making a 

4 request to the IDE controller to unlock the secure-private partition. 
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1 18. The system of claim 16, further comprising a requesting software and 

2 a privacy gatekeeper which acts as a gatekeeper to the security/privacy software 

3 task, wherein when the requesting software makes a request to access the 

4 secure-private partition, the privacy gatekeeper prescreens the request to 

5 determine if the requesting software has an authorization to access the secure- 

6 private partition. 

1 19. The system of claim 18, wherein the IDE controller allows an access 

2 to said at least one secure-private partition only when a valid access handshake 

3 is established between the requesting software and the IDE controller. 

1 20. The system of claim 19, wherein the IDE controller generates and 

2 return a usage token to the requesting software once the secure-private partition 

3 is unlocked, wherein the access handshake is established between the IDE 

4 controller and the requesting software when the IDE controller validates the 

5 usage token passed back by the requesting software. 
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ABSTRACT 

A system and method are described for providing a secure-private 
partition on a storage device of a computer system. The secure-private partition 
is normally invisible to an operating system unless the partition is unlocked. The 
secure-private partition is configured to unlock so that it is visible to the operating 
system in response to an unlock request received from a software task having 
knowledge about a proper handshake for unlocking the partition. 



17 



100 





102 




CACHE 
MEMORY 
107 




PROCESSOR 




105 



/ 



PROCESSOR BUS 110 



VIDEO 
DEVICE 
125 




CHIP SET 
120 




MAIN 
MEMORY 

m 




IDE 

CONTROLLER 







SYSTEM BUS 130 





SECONDARY BUS 150 



153 



DISK 
CONTROLLER 



HARD DISK 
DRIVE 

-SECURE-PRIVATE^ 
PARTITION ' 



STANDARD 
PARTITION 



REQUEST "MASTER TOKEN" 
FROM THE IDE CONTROLLER 



STORE THE MASTER TOKEN 
FOR LATER USE 



1 200 

r 



]x3 05 



FIG. 2A 





YES ^ 


RETRIEVETHE MASTER 
TOKEN 






r 


M 


REQUEST ACCESS BY 
PASSING THE MASTER 
TOKEN 



220 



OPEN (OR UNLOCK) THE 
SECURE-PRIVATE 
PARTITION 



GENERATE AND RETURN A 
NEW USAGE TOKEN FOR 
READ/W RITE ACCESS 

▼ 



EXECUTE READ/WRITE 
REQUESTS 



CLOSE ACCESS TO THE 
SECURE-PRIVATE 
PARTITION 



230 



235 



240 



245 



FIG. 2B 



k 300 

SUBMIT A READ/WRITE ^ 
REQUEST * 



PASS THE USAGE TOKEN ~^° 5 
TO THE IDE CONTROLLER 




400 



SECURITY/PRIVACY SYSTEM 



402 



PRIVACY 
GATE KEEPER 



1408 



SECURITY/PRIVACY 
SOFTWARE 
TASK 



MASTER 
TOKEN 



426 



USAGE 
TOKEN 



428 
424 



404 



406 



436 
^432 



412 



414 



434 



SECURE 
TOKEN 



REQUESTING 
SOFTWARE 



^^430 



IDE 

CONTROLLER 



418 



416 



420 



DISK CONTROLLER 



SECURE-PRIVATE 
PARTITION 



a. 



HARD 
DISK 
DRIVE 



STANDARD 
PARTITION 



FIG. 4 



422 



Attorney's Docket No.: 042390.P8691 



DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 
(FOR INTEL CORPORATION PATENT APPLICATIONS) 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name. 

I believe I am the original, first, and sole inventor (if only one name is listed below) or an original, first, and 
joint inventor (if plural names are listed below) of the subject matter which is claimed and for which a patent is 
sought on the invention entitled 

METHOD AND APPARATUS FOR PROVIDING A SECURE-PRIVATE 
PARTITION ON A HARD DISK DRIVE OF A COMPUTER SYSTEM VIA IDE 
CONTROLLER 

the specification of which 

Sis attached hereto, 
was filed on as 

United States Application Number 

or PCT International Application Number 

and was amended on 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified specification, including 
the claim(s), as amended by any amendment referred to above. I do not know and do not believe that the 
claimed invention was ever known or used in the United States of America before my invention thereof, or 
patented or described in any printed publication in any country before my invention thereof or more than one 
year prior to this application, that the same was not in public use or on sale in the United States of America more 
than one year prior to this application, and that the invention has not been patented or made the subject of an 
inventor's certificate issued before the date of this application in any country foreign to the United States of 
America on an application filed by me or my legal representatives or assigns more than twelve months (for a 
utility patent application) or six months (for a design patent application) prior to this application. 

I acknowledge the duty to disclose all information known to me to be material to patentability as defined in Title 
37, Code of Federal Regulations, Section 1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, Section 119(a)-(d), of any foreign 
application(s) for patent or inventor's certificate listed below and have also identified below any foreign 
application for patent or inventor's certificate having a filing date before that of the application on which priority 
is claimed: 

Prior Foreign Application^: 



APPLICATION 
NUMBER 


COUNTRY (OR 
INDICATE IF PCT) 


DATE OF FILING 
(day, month, year) 


PRIORITY CLAIMED 








□ No □ Yes 








□ No □ Yes 








□ No □ Yes 



I hereby claim the benefit under Title 35, United States Code, Section 1 19(e) of any United States 
provisional application(s) listed below: 



APPLICATION 
NUMBER 


FILING DATE 











INTEL CORPORATION 

Rev. 12/1 1/96 (D3 INTEL) cak Docket No . 042390.P8691 



I hereby claim the benefit under Title 35, United States Code, Section 120 of any United States application(s) 
listed below and, insofar as the subject matter of each of the claims of this application is not disclosed in the 
prior United States application in the manner provided by the first paragraph of Title 35, United States Code, 
Section 112, 1 acknowledge the duty to disclose all information known to me to be material to patentability as 
defined in Title 37, Code of Federal Regulations, Section 1.56 which became available between the filing date 
of the prior application and the national or PCT international filing date of this application: 



APPLICATION 
NUMBER 


FILING DATE 


STATUS (ISSUED, 
PENDING, ABANDONED) 





















I hereby appoint BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN, a firm including: William E. Alford, Reg. No. 37,764; 
Farzad E. Amini, Reg. No. 42,261; Amy M. Armstrong, Reg. No. 42,265; Aloysius T. C. AuYeung, Reg. No. 35,432; William 
Thomas Babbitt, Reg. No. 39,591; Carol F. Barry, Reg. No. 41,600; Jordan Michael Becker, Reg. No. 39,602; Bradley J. 
Bereznak, Reg. No. 33,474; Michael A. Bernadicou, Reg. No. 35,934; Roger W. Blakely, Jr., Reg. No. 25,831; Gregory D. 
Caldwell, Reg. No. 39,926; Ronald C. Card, Reg. No. 44,587; Thomas M. Coester, Reg. No. 39,637; Donna Jo Coningsby, Reg. 
No. 41,684; Michael Anthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No. 37,813; Robert Andrew Diehl, Reg. No. 
40,992; Matthew C. Fagan, Reg. No. 37,542; Tarek N. Fahmi, Reg. No. 41,402; Paramita Ghosh, Reg. No. 42,806; James Y. 
Go, Reg. No. 40,621; James A. Henry, Reg. No. 41,064; Willmore F. Holbrow HI, Reg. No. 41,845; Sheryl Sue Holloway, Reg. 
No. 37,850; George W Hoover II, Reg. No. 32,992; Eric S. Hyman, Reg. No. 30,139; William W. Kidd, Reg. No. 31,772; Sang 
Hui Kim, Reg. No. 40,450; Eric T. King, Reg. No. 44,188; Erica W. Kuo, Reg. No. 42,775; Michael J. Mallie, Reg. No. 
36,591; Paul A. Mendonsa, Reg. No. 42,879; Darren J. Milliken, Reg. No. 42,004; Chun M. Ng, Reg. No. 36878; Thien T. 
Nguyen, Reg. No. 43,835; Thinh V. Nguyen, Reg. No. 42,034; Dennis A. Nicholls, Reg. No. 42,036; Lisa A. Norris, Reg. No. 
44,976; Daniel E. Ovanezian, Reg. No. 41,236; William F. Ryann, Reg. No. 44,313; James H. Salter, Reg. No. 35,668; William 
W. Schaal, Reg. No. 39,018; James C. Scheller, Reg. No. 31,195; Jeffrey S. Smith, Reg. No. 39,377; Maria McCormack 
Sobrino, Reg. No. 31,639; Stanley W. Sokoloff, Reg. No. 25,128; Judith A. Szepesi, Reg. No. 39,393; Vincent P. Tassinari, 
Reg. No. 42,179; Edwin H. Taylor, Reg. No. 25,129; Joseph A. Twarowski, Reg. No. 42,191; Lester J. Vincent, Reg. No. 
31,460; Glenn E. Von Tersch, Reg. No. 41,364; John Patrick Ward, Reg. No. 40,216; Charles T. J. Weigell, Reg. No. 43,398; 
James M. Wu, Reg. No. 45,241; Steven D. Yates, Reg. No. 42,242; and Norman Zafraan, Reg. No. 26,250; my attorneys; and 
Andrew C. Chen, Reg. No. 43,544; Justin M. Dillon, Reg. No. 42,486; and John F. Travis, Reg. No. 43,203; my patent agents, 
with offices located at 12400 Wilshire Boulevard, 7th Floor, Los Angeles, California 90025, telephone (310) 207-3800, and Alan 
K. Aldous, Reg. No. 31,905; Robert D. Anderson, Reg. No. 33,826; Joseph R. Bond, Reg. No. 36,458; Richard C. Calderwood, 
Reg. No. 35,468; Jeffrey S. Draeger, Reg. No. 41,000; Cynthia Thomas Faatz, Reg No. 39,973; Sean Fitzgerald, Reg. No. 
32,027; Seth Z. Kalson, Reg. No. 40,670; David J. Kaplan, Reg. No. 41,105; Charles A. Mirho, Reg. No. 41,199; Leo V. 
Novakoski, Reg. No. 37,198; Naomi Obinata, Reg. No. 39,320; Thomas C. Reynolds, Reg. No. 32,488; Kenneth M. Seddon, 
Reg. No. 43,105; Mark Seeley, Reg. No. 32,299; Steven P. Skabrat, Reg. No. 36,279; Howard A. Skaist, Reg. No. 36,008; 
Steven C. Stewart, Reg. No. 33,555; Raymond J. Werner, Reg. No. 34,752; Robert G. Winkle, Reg. No. 37,474; and Charles K. 
Young, Reg. No. 39,435; my patent attorneys, and Peter Lam, Reg. No. P44,855; Thomas Raleigh Lane, Reg. No. 42,781; Gene 
I. Su, Reg. No. 45,140; and Calvin E. Wells, Reg. No. P43,256; my patent agents, of INTEL CORPORATION with full power 
of substitution and revocation, to prosecute this application and to transact all business in the Patent and Trademark Office 
Send correspondence to Walter T. Ki m. Reg. No. 42.731 . BLAKELY, SOKOLOFF, TAYLOR & 
(Name of Attorney or Agent) 

ZAFMAN LLP, 12400 Wilshire Boulevard, 7th Floor, Los Angeles, California 90025 and direct telephone 
calls to Walter T. Kim. Reg. No. 42.731 . (310) 207-3800. 

(Name of Attorney or Agent) 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on 
information and belief are believed to be true; and further that these statements were made with the knowledge 
that willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code and that such willful false statements may jeopardize the validity of 
the application or any patent issued theif— 
Full Name of Sole/First /Inventory 

Inventor's Signature 



Residence Portland, Oregon 




Kelan C. Silvester 

Date Jgsie, Zf 



(City , State) 

P. O. Address 19840 NW Metolius Drive 



_ Citizenship 



Portland, Oregon 97229 USA 



Docket No. 042390.P8691 



